Advances in silicon technology increasingly allow larger and more complex designs to be formed on a single chip. Components on a chip may be organized into system blocks. A system block is a model of a component on a chip, e.g., a CPU, a bus, or a timer. Designs may consist of millions or tens of millions of transistors on a single chip. At the same time, however, market demands continue to push designers to develop designs more rapidly and efficiently. As a result, designers strive to increase the performance of system blocks, which may be measured by characteristics such as timing and accuracy.
A transaction is a discrete operation on the signal level, e.g., writing one or more bytes from CPU to memory. Models for processing transactions (“transaction models”), operating at different levels of abstraction, may be used by a system designer in designing and testing system blocks. In general, the level of abstraction of a model is inversely proportional to the accuracy of the model and directly proportional to the speed of simulation of the models. In other words, as the level of abstraction increases, the speed of simulation increases while the accuracy decreases.
The design of a system block may initially be tested using a transaction model, such as a TLM model. Subsequently, the design of the system block may be tested and validated at lower levels of abstraction, e.g., via a RTL equivalent model. Transaction models operating at a high-level of abstraction shall be referred to as TLM (transaction level modeling) models. Transaction level modeling refers to a high-level approach to modeling digital systems where communication among modules are separated from the details of the implementation of the functional units. TLM models operating at a high-level of abstraction may have a corresponding model operating at a low-level of abstraction, such as a RTL (register transfer level) model. Register transfer level refers to the level of abstraction at which a digital system is described as synchronous transfer between functional units.
A testbench may be used in the testing and validation of the system blocks using transaction models. A testbench, in this context, is an application that may apply a set of stimuli (such as a test vector) to a model to produce a set of information used in analyzing the timing or performance of a system block. One non-limiting, illustrative example of a tool capable of operating on a TLM model is the Virtual Component Co-design (“VCC”) tool available from Cadence Design Systems located in San Jose, Calif. A non-limiting, illustrative example of a tool capable of operating upon a RTL equivalent model is the NC-Sim tool available from Cadence Design Systems located in San Jose, Calif.
It is advantageous that the transaction models to be as accurate as possible to aid the system designer. The validation of the transaction models involves not only accessing how accurate the TLM model is compared with the RTL equivalent model, but also where the tradeoffs lie with respect to simulation speed and accuracy. In the prior art, the performance of transaction models have not been validated against RTL equivalent models because the transaction models have been primarily built to showcase the capabilities of the testbench, which is undesirable because it undermines the accuracy of the performance of the transaction model. Additionally, the validation of TLM models with respect to their RTL equivalent models are performed on a case-by-case basis. In other words, a TLM model is validated first, and then the corresponding RTL equivalent models is validated independently of the TLM model. There currently exists no mechanism for testing and validating TLM models against their RTL equivalent models using the same set of stimuli. As the two worlds (between the TLM models and the RTL models) are completely disconnected, separate testbenches are required to test the TLM models and the RTL equivalent models. Using separate testbenches for testing models of different levels of abstraction prevents accurate comparisons between the models.
The disconnect between the TLM models and the RTL equivalent models produces even further problems in the art. Both TLM models and the RTL equivalent models are used to test the timing and duration of transactions in the system block. The timing of the same transaction using a TLM model and a RTL equivalent model generally may not match, because the TLM model may be cycle approximate, while the RTL equivalent model may be cycle accurate. In a cycle accurate model, accurate cycle counts are available for each transaction that is processed. Events that occur during the processing of a transaction are indicated with precision as to which clock cycle they occur in. On the other hand, in a cycle approximate model, only approximate cycle counts are available for events occurring during transaction processing because the model is not complete as to every aspect, e.g., modeling of pipelining and cache effects may not be completely accurate. Accordingly, it is difficult to account for discrepancies detected in the duration or timing of a transaction between the TLM model and a corresponding RTL equivalent model because the differences between the testing and validation environments between the high-level of abstraction and low-level of abstraction is compounded by an inability to accurately align clock cycles. Accordingly, there is a need in the art for improved performance analysis in transaction level models
Accordingly, the present invention provides for improved method for effecting performance analysis upon a system block. In an embodiment, a system block is modeled in both a TLM model and a RTL equivalent model. Next, a testbench generates a set of stimuli, where the testbench is an application that may apply the set of stimuli against the TLM model or the RTL equivalent model to produce a set of timing information. Thereafter, performance analysis is effected on the TLM model using the set of stimuli, and performance analysis is effected on the RTL equivalent model using the set of stimuli. Further details of aspects, objects, and advantages of the invention are described below in the detailed description, drawings, and claims.